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METHOD AND SYSTEM FOR SEAMLESS MOBILITY OF MOBILE 
TERMINALS IN A WIRELESS NETWORK 



FIELD OF THE INVENTION 

The present invention relates to roaming by mobile terminals in wireless networks, 
and more particularly, to support of L3 handovers for seamless mobility during the roaming 
in the wireless networks. 

BACKGROUND OF THE INVENTION 

Wireless communication has seen tremendous growth in recent years and is 
becoming widely applied to personal and business computing. Wireless access is 
broadening network reach by providing convenient and inexpensive access in hard-to-wire 
locations. Of major benefit is the increased mobility wireless local area networks (WLANs) 
allow. Wireless LAN users can roam seemingly without restriction and with access from 
nearly anywhere without being bounded by conventional wired network connections. 

One of the most significant issues in the area of wireless and mobile communications 
technology is the provision of constant IP (Intemet protocol)-connectivity to mobile nodes 
upon roaming. While the IEEE 802.1 1 standard for WLANs acts as an important milestone 
in the evolution of wireless networking technology, roaming has not yet gained much 
coverage in the current IEEE 802.1 1 standard, resulting in insufficient support of key 
mobility functions. 

Referring concurrently to Figures 1 and 2, a typical IEEE 802.1 1 infrastructure 
WLAN environment consists of access points 10a, 10b, 10c, lOd, lOe (APs) and mobile 
terminals/stations 12a, 12b (STAs) communicating over the air via 802.1 lb specific 
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messages. Neighboring APs are attached to a wired distribution system 14 (DS) and form 
an extended service set 16a, 16b, 16c, 16d (ESS), Upon power up, a STA 12a gets 
associated to an AP 10a inside the ESS 16a within which it is residing via specific 
association messages. At the same time, it obtains an IP address (e.g., via DHCP, Dynamic 
Host Configuration Protocol) so as to be widely reachable at its current location. 
Furthermore, certain authentication procedures take place (e.g., 802. Ix authentication) in 
order to authenticate the STA 12a. The IP subnet 1 8a where the STA's IP address belongs is 
called the home network (HN). Every time the STA 12a powers up inside an ESS 16a, the 
lAPP (Inter- Access Point Protocol) is triggered so as to inform the neighboring APs 10b 
about the STA's 12a physical location. This is accomplished via specific layer 2 (L2) 
message updates sent by the home access point (HAP) 10a to the subnet broadcast address. 
Routing of the IP datagrams is performed via standard IP routing mechanisms. The APs 
10a, 10b are used as L2 bridges. Any packets sourcing outside the HN and destined to the 
STA 12a, arrive at the gateway router 20a of the corresponding ESS 16a. Inside the ESS 
16a, specific L2 bridging takes place to successfully deliver packets to the STA's actual 
location. 

Within the ESS 16a, the STAs 12a, 12b may roam from one AP (e.g., 10a) to another 
AP (e.g., 10b) via reassociation messages. In an 802.1 1 WLAN, each time a STA 12a is 
reassociating to a new AP 10b inside the ESS 16a of its HN, it performs an intra-network 
handover. The L2 point of attachment has changed to the MAC address of the new AP 10b, 
and the new AP 10b becomes the STA's HAP (home AP). The STA 12a preserves its MAC 
address. The time elapsed between the cut-off of the previous AP-STA and the connection 
running between the new AP and the STA is called the handover period or handover 
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recovery time. During this period, any active sessions that this STA 12a had before its 
movement get disconnected. The L2 handover of 802. 1 1 STAs is supported by the lAPP 
protocol, which provides the necessary means for quick recovery of the interrupted active 
sessions. Moreover, it assures that the STA is still able to send/receive IP packets from its 
new location while preserving its home IP address. 

For inter-network handover in IEEE 802.1 1 WLANs, the STA 10a moves inside an 
ESS 16b that belongs to a different IP subnet, i.e., it triggers a layer 3 (L3) handover. This 
type of handover is performed when a roaming STA 12a reassociates to a foreign AP 10c of 
an ESS 16b outside of its home network and involves both an L2 and an L3 handoff 
(Similarly, if a STA already lying in a foreign network roams inside/between foreign 
networks, it still performs an L3 handover.) 

Thus, via specific 802.1 1 MAC layer mechanisms, the STA 12a is now physically 
attached to a foreign AP 10c. However, it was not one of the lAPP objectives to provide 
support for inter-network (L3 or IP) handover of 802.1 1 roaming STAs. Accordingly, any 
packets now destined to the home address of the STA 12a are routed to its HN. However, 
these packets will be dropped due to the fact that the STA 12a does not physically belong 
there anymore. Similarly, any packets originated from the STA 12a will be dropped inside 
the foreign network, because their source IP address does not belong to this subnet. 

All of these routing issues arising upon an L3 handover form a problem that is 
outside the scope of the lAPP. With the increasing deployment of 802. 1 1 networks in both 
commercial and home environments, the need for inter-network handover increases. The 
present invention addresses this need, ensuring constant IP-connectivity during any type of 
handover (IP or MAC layer) to assist in unbounded roaming of 802.1 1 STAs. 



2819P 



3 



SUMMARY OF THE INVENTION 

Aspects for seamless mobility of mobile terminals in a wireless network are 
described. The aspects include utilizing a reassociation request from a mobile terminal to 
identify need for an internetwork handover of the mobile terminal roaming in a wireless 
local area network (WLAN), and performing a protocol sequence in an access point (AP) for 
the mobile terminal to handle the internetwork handover to ensure connectivity of the 
mobile terminal while roaming. 

Through the present invention, the IP-flows of roaming mobile terminals are 
preserved even when the mobile terminals move across different sub-networks. Further, the 
protocol sequence of the present invention requires no changes in the protocol stack of the 
802. 11 mobile terminals, and the handover is supported in a way that is transparent to the 
mobile terminals. In addition, real-time and critical sessions are maintained with quick 
restoration of IP-connectivity via low-loss and low-latency handover that integrates to the 
existing IEEE 802.1 1 standard, instead of requiring the additional use of separate handover 
protocols, such as Mobile IP. These and other advantages will become readily apparent 
from the following detailed description and accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 illustrates a wireless network system in accordance with the prior art. 

Figure 2 illustrates inter-network movements in the wireless network of Figure 1. 

Figure 3 illustrates a protocol stack in accordance with the present invention. 

Figures 4a and 4b illustrate a method supporting handover movements in accordance 
vsdth the present invention. 
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Figure 5a illustrates a general 802.1 If lAPP packet of the prior art. 
Figure 5b illustrates a data field for the packet of Figure 5 a. 

Figures 5c and 5d illustrate data fields for the packet of Figure 5a in accordance with 
the present invention. 

Figures 6a, 6b, and 6c illustrate pseudo-code for the activities of the APs during 
handover movements in accordance with the present invention. 

Figures 7 and 8 illustrate routing diagrams and datagrams in accordance with the 
present invention. 

DETAILED DESCRIPTION 

The present invention relates to seamless mobility support for mobile terminals in a 
wireless network. The following description is presented to enable one of ordinary skill in the 
art to make and use the invention and is provided in the context of a patent application and its 
requirements. Various modifications to the preferred embodiment and the generic principles 
and features described herein will be readily apparent to those skilled in the art. Thus, the 
present invention is not intended to be limited to the embodiment shown but is to be accorded 
the widest scope consistent with the principles and features described herein. 

In general, the present invention extends lAPP fiinctionality rather than replacing it 
and is added in the existing protocol stack of IEEE 802.1 1 APs, as indicated by the Radius 
client layer in the protocol stack illustrated in Figure 3 . Further, the aspects of the protocol 
sequence of the present invention are utilized only if an L3 handover is identified by an AP 
upon receipt of an IEEE 802.1 1 Reassociation.Request message by a STA. If no L3 
handover is identified, standard lAPP takes place to handle the L2 handover. An L3 
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handover identification preferably occurs based on IP specific information which is retrieved 
by the 802.1 1 Reassociation.Request frame, which is extended in accordance with the 
present invention to include three new fields that are the only changes required by the STAs 
for the aspects of the present invention to be applicable to 802.1 1 L3 handovers. The fields 
are: (1) HAP IP address; (2) STA IP address; and (3) Previous AP (PAP) IP address. 

Referring now to Figures 4a and 4b, in accordance with the present invention, the 
sequence of actions during L3 handover during inter-network movement and inter/intra- 
foreign-network movement, respectively, are shown. For inter-network movement, the 
sequence initiates upon receipt of a reassociation request from a STA 40 to a NAP 42. The 
NAP 42 adds a routing entry for the STA 40 and creates a tunnel to the HAP 44. The NAP 
42 further sends an L3-MOVE-notify-type packet to the HAP 44. The HAP 44 in turn 
registers the FACOA (foreign agent care of address) for the STA and creates a tunnel to the 
NAP 42. The HAP 44 then sends an L3-MOVE-response-type packet to the NAP 42. In the 
inter/intra-foreign network movement, the NAP 46 performs the same sequence with the 
HAP 44. However, the sequence also includes a TUNNEL request being sent from the NAP 
46 to the PAP 42 when the L3-MOVE-notify-type packet is sent to the HAP 44. In 
response, the PAP 42 registers the STA new FACOA, creates a tunnel to NAP 46, and 
deletes the HAP-PAP tunnel entries. The PAP 42 then sends a TUNNEL response to the 
NAP 46. 

While MOVE-notify- and -response-type packets are presented with reference to 
Figures 4a and 4b, these packet types, as defined in IEEE 802.1 If D3.1, are modified in 
accordance with the present invention. Figure 5a illustrates a standard format for these 
packet types, while Figure 5b illustrates a standard format for the data field of these packet 
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types. These packets types are modified to provide new lAPP-based packets (TCP/IP and 
UDP/IP packets) in accordance with the present invention for exchange between the 
involved parties of a STA*s L3 handover. These new packets are Roam-request, Roam- 
response, Create-Tunnel-request, and Create-Tunnel-response. Along with the new packets, 
new service primitives are generated at the corresponding APs and are analogous to standard 
lAPP service primitives. These new service primitives are the Roam.Request primitive, 
Roam.Response primitive, Create-Tunnel.Request primitive, and Create-Tunnel.Response 
primitive. 

A Roam.request primitive is generated at a NAP only in the case of a STA's network 
handover when the NAP receives an MLME-Reassociate.indication . The NAP then sends a 
Roam-request packet to the HAP and an L2 update frame to the subnet broadcast address, 
which may be useful in situations where the APs support dynamic routing. The Roam- 
request packet, a TCP/IP packet, causes registration of the FACOA to the HAP and triggers 
HAP-NAP tunnel establishment. The Roam-request packet is the same as the lAPP Move- 
notify request packet with an extension to also carry the HAP and STA IP addresses. Since 
the command values of 0-4 are reserved by the 802. 1 If lAPP packets, a command value of 5 
is suitable for the packet generated, and a preferred data field for the packet is illustrated in 
Figure 5c. 

Upon receipt of a Roam-request packet from the NAP of a STA, the Roam.response 
primitive is generated at the HAP. The HAP then sends a Roam-response packet to the NAP 
indicating the successful creation of the HA-NAP tunnel at the HAP. The Roam-response 
packet, a TCP/IP packet, is the same as the lAPP Move-response packet with an extension to 
also carry the HAP and STA IP addresses. For the packet fields, the status field suitably 
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indicates success or failure of the tunnel creation, while the command field has a distinctive 
command value, e.g., 6, and the data field is structured as illustrated in Figure 5c. 

The Create-Tunnel.request primitive is generated at an AP acting as a NAP for a 
STA in cases of intra/inter-foreign-network movements and causes the sending of a Create- 
Tunnel-request packet to the PAP of the STA. The Create-Tunnel-request packet, a UDP/IP 
packet exchanged from the NAP to the PAP, informs the PAP of the new FACOA and 
triggers NAP-PAP temporary tunnel establishment. The Create-Tunnel-request packet is the 
same as the lAPP MOVE-notify packet with an extension to also carry the STA IP address. 
For the packet, the command field has a suggested value of 7. The remote end AP of the 
tunnel to be created (i.e., RE=NAP) is indicated in the REIP field, and the STA is specified 
in the MAC address and MNIP fields, as illustrated in the data field of Figure 5d. 

In cases of intra/inter-foreign-network movements, the Create-Tunnel.response 
primitive is generated at the PAP of a STA and causes the PAP to send a Create-Tunnel- 
response packet to the NAP of the STA. The Create-Tunnel-response packet, a UDP/IP 
packet, indicates completion of the PAP's actions for the PAP-NAP tunnel establishment to 
the NAP. The Create-Tunnel-response packet is the same as the lAPP Move-response 
packet with an extension to also carry the STA IP address. Thus, the packet's data field is 
the same as that of the Create-Tunnel-request with the reserved field replaced by a status 
field having a success or failure value. A value of 8 is suggested for the command value. 

In addition to the packets and primitives, in accordance with the present invention, 
the management entity architecture of the AP is enhanced. Every AP acting as a HAP 
preserves a list (RoamingList) for its registered STAs that currently use a FACOA. Further, 
every AP serving as a FA preserves a list (VisitorList) with the currently connected STAs 
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for which the FA has established tunnels toward the STA's HAP. For each AP involved in 
the L3 handover, it identifies its current role (NAP, HAP, or PAP) and performs the 
appropriate actions, as described hereinabove and presented in the pseudo-code of Figures 
6a, 6b, and 6c. 

The concept of IP tunneling is used in the present invention to provide the important 
functionalities at the involved APs of session re-establishment and routing of IP datagrams 
after handover completion. These are both achieved via IP encapsulation and decapsulation 
of the STA's IP datagrams by the APs. 

Referring to Figure 7, for inter-network movement, in the forward direction (to the 
STA), the HAP 50 is able to route packets to the current location of the mobile terminal via 
IPIP encapsulation. The IP header of any packets in this direction has the IP address of the 
corresponding node (CN) 52 as a source address (SA) and the STA's 58 IP address as the 
destination address (DA). When the packet reaches the HAP 50, an additional IP header is 
added to the packet, as shown. The encapsulated datagram is forwarded to the NAP 54 
through the existing HAP-NAP tunnel. The NAP 54 (FA) decapsulates/strips the outer IP 
header off of all packets destined to the STA's IP address and routes them to the directly 
connected STA 58 (ARP entry). 

For inter-network movement in the backward direction (from the STA), the NAP 54 
is able to route packets originated at the current location of the mobile terminal via IPIP 
encapsulation. The IP header of any packets sourced at the STA 58 includes a SA of STA 
IP and a DA of CN IP. When the NAP 54 has to route such packets, it does so using the 
HAP-NAP tunnel 56. The NAP 54 encapsulates the STA's packets by adding an outer 
header, as shown. The encapsulated datagram is forwarded to the HAP 50 through the 
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existing HAP-NAP tunnel 56. There, the HAP 50 decapsulates/strips off the outer IP header 
of the packet and routes the initial packet to the original DA (which is the CN 52). 

For inter/intra-foreign network movement, the STA 58 becomes associated to a new 
foreign AP (NAP 60, Figure 8). The NAP 60 may belong to the same FN or another FN. 
After completion of the protocol of the present invention, a new bi-directional HAP-NAP 
tunnel is established, which serves the routing of the STA's IP datagrams, and the previous 
HAP-PAP tunnel is deleted after successful establishment of the new tunnel. Routing of the 
IP datagrams after handover completion is supported by the same routing methods presented 
with reference to Figure 7. For fast and low-loss handoff purposes, a temporary PAP-NAP 
tunnel 62 is created before the HAP-PAP tunnel deletion. The session re-establishment is 
supported by the use of the NAP IP address as the STA's FACOA. Further, any packets that 
remained at the PAP after movement of the STA are forwarded to the STA's current AP, the 
NAP, through the temporary PAP-NAP tunnel. Upon receipt of these packets, the NAP 
routes them to the DA specified by the IP header of the packets, i.e., the STA IP address 
(existing STA ARP entry). 

Thus, the present invention considers APs able to perform IP-in-IP encapsulation in 
order to utilize the IP tunneling and reverse tunneling methods. In this manner, a feasible 
and efficient way for supporting all forms of mobility of IEEE 802.1 1 mobile terminals is 
provided. Without such a mechanism, IP routing is not feasible in cases of L3 mobility 
within 802. 1 1 environments. 

From the foregoing, it will be observed that numerous variations and modifications 
may be effected without departing from the spirit and scope of the novel concept of the 
invention. It is to be understood that no limitation with respect to the specific methods and 
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apparatus illustrated herein is intended or should be inferred. It is, of course, intended to 
cover by the appended claims all such modifications as fall within the scope of the claims. 
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